home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / lisp / kcl / akcl / akcl1615.lha / doc / enhancements < prev    next >
Text File  |  1987-12-12  |  6KB  |  147 lines
  1.  
  2.  
  3. @chapter Loading Object Code
  4.  
  5. We will outline some of the features of the object loader, by William
  6. Schelter.
  7.  
  8. When you do @code{(load "foo.o")} the output from the C compiler,
  9. must be loaded into static space in the running KCL, and references
  10. to external symbols must be resolved.  Originally KCL used the
  11. loader from the underlying lisp system, calling it in a subshell,
  12. to produce yet another file, which had the correct references
  13. to externals.   This was then read into kcl.  The data vector (a lisp
  14. readable vector at the end of the object file) was also read into KCL.
  15.  
  16. Unfortunately some operating systems (such as System V) do not supply
  17. a loader capable of doing this relocation, and in any event it is fairly
  18. slow.   Also there was no possiblity of incrementally adding new external
  19. C symbols to an already running lisp, and then having future files refer
  20. to them.  For example you might have a function @code{search1} written
  21. in C, which you wished to access directly in subsequently loaded files.
  22. This was not possible since the loader only knew about the addresses
  23. of the external symbols in the original saved image.  
  24.  
  25. The new scheme builds a list of the external symbols into a table
  26. called @code{c_table}.  This table is built by examining the current image.
  27. It will be built automatically with the first call to load.  Subsequent
  28. calls just use this table.   Of course there is the additional benefit,
  29. that it is easy to add additional symbols to the table.  
  30.  
  31. For example if you have a file @file{try.c} which looks like
  32.  
  33. @code@{init_code()
  34. add_symbols(joe,&joe,pete,&pete,NULL);
  35. @}
  36.  
  37. joe(x)
  38. object x
  39. @{...@} 
  40.  
  41. pete()
  42. @{...@} 
  43. }
  44.  
  45. then joe and pete will be added to the symbol table of the current kcl.
  46. You may refer to them as external variables in subsequent files, and
  47. these files will load correctly, referencing these variables.   It is an error
  48. apply add_symbol twice, to the same variable.  
  49.  
  50. The loading of files has speeded up considerably, so that a small file
  51. with only a few small functions in it, can be loaded in less than .05 seconds.
  52.  
  53.  
  54. @chapter Metering and Profiling
  55.  
  56. KCL utilities have been added, by W. Schelter, to allow one to
  57. determine the percentage of time spent in individual functions.
  58.  
  59. Usage involves deciding which block of code one wishes to profile,
  60. that is to say what address range, and then allocating an appropriate
  61. size @code{*profile-array*}.  For example in the Sun version, if you
  62. have loaded a few object files, then if you wish to meter all of kcl
  63. and the files which you loaded you could allocate a 1 megabyte array.
  64. This would give a roughly 2 to one reduction relative to the code
  65. address range.  Note that the loader prints out the address at which
  66. code is loaded.  There is also a function @code{si@:function-start
  67. (fun)} which returns the start address of a compiled function.
  68.  
  69. In the above example after loading the file lsp/profile.o  you 
  70. could do
  71. @code{(si:set-up-profile 1000000)}
  72.  
  73. This allocates the 1 megabyte array, and also reads in the c symbol
  74. table, if this has not already been done.  It also gets the addresses
  75. of all compiled function objects currently in the image, and keeps
  76. them in a table.  This table is called @code{combined_table} at the C
  77. level.  The function @code{si:set-up-combined (size-of-table)} sets up
  78. a combined table for the lisp and C functions.  This function is
  79. called by the previous @code{si:set-up-profile} function, with a
  80. default size-of-table of 6000.
  81.  
  82. Now to turn profiling on you do @code{(si::prof 0 90)}.  This will
  83. start metering all addresses in the range of 0 (the first arg) to
  84. 1,000,000 * (256/90), where 90 is the second arg.  To display the data
  85. collected so far you can invoke @code{si::display-profile} with no
  86. arguments.  In order to clear the profile array you run
  87. @code{(si::clear)}.  A call of @(si::prof 500000 256) would
  88. profile the code in the address range of 500,000 to 1,500,000.
  89. You may switch the profiler off by specifying a 0 mapping, 
  90. ie @code{si::prof 0 0)}.   It can then be restarted by supplying
  91. a nonzero second argument.  Of course if you start up again
  92. with a scale different from the previous one,
  93. without clearing the profile array, you will have gibberish.
  94.  
  95. The argument list to the last call of @{si::prof} is stored in the
  96. variable @code{si::*current-profile*}.
  97.  
  98. Unless one is using a one to one mapping of the profile array
  99. to the code, there is a possibility of quantization errors.
  100. There is also the possibility of overflowing a slot in the profile
  101. array, if the mapping is very coarse, or if the interval being measured
  102. is very long.  
  103.  
  104. @code{
  105.   0.08% (    9): _eql
  106.  15.26% ( 1822): _equal
  107.   0.01% (    1): _Fquote
  108.   0.01% (    1): SET
  109.   0.04% (    5): _parse_key
  110.   0.01% (    1): _Fcond
  111. ...
  112.   0.50% (   60): RELIEVE-HYPS1
  113.   0.03% (    4): REMAINDER
  114.   0.01% (    1): REMOVE-*2*IFS
  115.   0.03% (    3): REMOVE-TRIVIAL-EQUATIONS
  116.   4.35% (  520): REWRITE
  117.   0.47% (   56): REWRITE-CAR-V&C-APPLY$
  118. ...}
  119.  
  120. is a sample of the output.  The first column represents percentage of
  121. total time spent with the program counter in the range starting at
  122. this function, up to the next named function. The second column is the
  123. actual number of times that a profile interrupt landed in this section
  124. of the code.  Note the default display is by address, and as mentioned
  125. before, one should beware of overlaps, in a coarse mapping.  Functions
  126. for which there were no ticks, are not displayed.
  127.  
  128. Note we did not sort the output, since we wished to leave it in address
  129. order.  It is possible (because of roundoff if the second arg to prof
  130. is small) that some calls could be credited to the adjacent function.
  131. This could be spotted more easily if the order is by address.
  132. It is trivial to sort the table by ticks in gnu emacs using the command
  133. sort-columns. Have the  point set at the beginning of column, in the first line
  134. and the mark at the end of the column in the last line.
  135.  
  136. Unfortunately the System V loader likes to separate the original C
  137. functions of KCL, from those incrementally loaded, by about 2 megabytes.
  138. This makes it awkward to meter both ranges simultaneously without using
  139. a very large profile array.   It is probably reasonable to rewrite the
  140. basic interrupt call, to handle such an address configuration.  This
  141. has not yet been done.   Of course you can always make two runs, and combine
  142. the information for the two ranges.
  143.  
  144.  
  145.  
  146.  
  147.